<!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN""http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html lang="zh" xml:lang="zh" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<head>
<META http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Guideline: Service Realization - BPEL services in a SOA application</title>
<meta name="uma.type" content="Guideline">
<meta name="uma.name" content="service_realization">
<meta name="uma.presentationName" content="Service Realization - BPEL services in a SOA application">
<meta name="element_type" content="other">
<meta name="filetype" content="description">
<meta name="role" content="">
<link rel="StyleSheet" href="./../../../css/default.css" type="text/css">
<script src="./../../../scripts/ContentPageResource.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/ContentPageSection.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/ContentPageSubSection.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/ContentPageToolbar.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/contentPage.js" type="text/javascript" language="JavaScript"></script><script type="text/javascript" language="JavaScript">
					var backPath = './../../../';
					var imgPath = './../../../images/';
					var nodeInfo=null;
					contentPage.preload(imgPath, backPath, nodeInfo,  '', false, false, false);
				</script>
</head>
<body>
<div id="breadcrumbs"></div>
<table border="0" cellpadding="0" cellspacing="0" width="100%">
<tr>
<td valign="top"><a name="Top"></a>
<div id="page-guid" value="_QNuHcEV1Edqpo8Lgp7-Wmg"></div>
<table border="0" cellspacing="0" cellpadding="0" width="100%">
<tr>
<td class="pageTitle" nowrap="true">Guideline: Service Realization - BPEL services in a SOA application</td><td width="100%">
<div align="right" id="contentPageToolbar"></div>
</td><td width="100%" class="expandCollapseLink" align="right"><a name="mainIndex" href="./../../../index.htm"></a><script language="JavaScript" type="text/javascript" src="./../../../scripts/treebrowser.js"></script></td>
</tr>
</table>
<table width="100%" border="0" cellpadding="0" cellspacing="0">
<tr>
<td class="pageTitleSeparator"><img src="./../../../images/shim.gif" alt="" title="" height="1"></td>
</tr>
</table>
<div class="overview">
<table width="97%" border="0" cellspacing="0" cellpadding="0">
<tr>
<td width="50"><img src="./../../../images/guidance.gif" alt="" title=""></td><td>
<table class="overviewTable" border="0" cellspacing="0" cellpadding="0">
<tr>
<td valign="top">This guideline describes an application that is built using BPEL based choreography in an SOA style.</td>
</tr>
</table>
</td>
</tr>
</table>
</div>
<div class="sectionHeading">Relationships</div>
<div class="sectionContent">
<table class="sectionTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<th class="sectionTableHeading" scope="row">Related Elements</th><td class="sectionTableCell">
<ul>
<li>
<a href="./../../../rup_soa_plugin/workproducts/soa_svce_model_svce_collab_76358B24.html" guid="{9BBBE5B0-4D39-4555-9E20-0ADBD8327D29}">Service Collaboration</a>
</li>
</ul>
</td>
</tr>
</table>
</div>
<div class="sectionHeading">Main Description</div>
<div class="sectionContent">
<table class="sectionTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td class="sectionTableSingleCell"><a id="XE_service_realization__guidelines_for" name="XE_service_realization__guidelines_for"></a> 
<h3>
    Introduction
</h3>
<p>
    This page describes an application that is built using BPEL based choreography in an SOA style. The lessons learned
    during both the design and development phases of this project provide general insight for others considering the use of
    BPEL based choreography in an SOA. The design approach is evaluated here using a Pros and Cons comparison that takes
    the business requirements and the existing application elements into consideration. This page contains design
    recommendations and identifies characteristics that suggest use of a BPEL driven approach.
</p>
<h3>
    Lessons learned
</h3>
<ol>
    <li>
        Choosing the right segmentation of business logic between the workflow and partner services is sometimes
        challenging and always important.<br />
        <br />
        <div style="MARGIN-LEFT: 2em">
            The business logic is separated between workflow based choreography and the partner services. Ultimately
            partner services should be responsible for computationally intensive or complex logic; whereas choreography
            contains the logic that is anticipated to change in response to changing business requirements.<br />
            <br />
            Since this will not always be a clean separation, a useful remediation strategy is to design the application so
            it grows by modifying the workflow and adding new partner services rather than modifying existing partner
            services.<br />
            <br />
            This is fundamentally an iterative approach. Early prototypes are likely to require refactoring of the partner
            services in order to achieve a design that can grow by addition of new partner services.<br />
            <br />
            Of course, in all cases you should keep un-necessary or never-changing code out of the work flow
        </div><br />
    </li>
    <li>
        Leverage the unique capabilities of BPEL<br />
        <br />
        <div style="MARGIN-LEFT: 2em">
            The ability of BPEL to orchestrate partner services which expose a variety of different bindings.<br />
            <br />
            Be careful not to build dependencies on the characteristics of a particular partner implementation or partner
            service binding. Doing so may complicate or limit later changes to the choreography or overall
            application.<br />
            <br />
            Consider keeping intermediate results in BPEL variables as a strategy to improve performance
        </div><br />
    </li>
    <li>
        Where possible design partner services in a stateless manner with idempotent operations.<br />
        <br />
        <div style="MARGIN-LEFT: 2em">
            For the purposes of this discussion, idempotence simply means that a service can be called with the same input
            data multiple times with the expectation that the response will be correct for each call. This characteristic
            can provide significant simplification for both caller and service since it dramatically simplifies the
            interaction. Error recovery, restart after failure, and scaling through clustering are all simplified. For the
            caller, error recovery from network, server and client problems is simplified. Idempotence is a key indicator
            for a potentially good match for BPEL choreography of partner services.<br />
            <br />
            Of course, if more complex interactions are required, the Web Services protocols include compensation
            capabilities that can be employed in such cases. All things being equal, if you can avoid such requirements in
            the overall application design, the result will be easier to maintain and test.
        </div>
    </li>
</ol>
<h3>
    The Case Study
</h3>
<p>
    This case study describes an IBM project to upgrade the information technology used by its ServicePac&reg; business. The
    goal of this project was to relieve specific pain points and position the ServicePac&reg; business for continued expansion
    in both volume and capabilities.
</p>
<p>
    Like many successful businesses, IBM's ServicePac&reg; business has gone through a sequence of incremental transitions,
    starting with the combination of many distinct warranty programs into three businesses organized by geographical
    sector. Later, geographically distinct operations were combined into a single world-wide operation. Over the years, the
    ServicePac&reg; business has continually added new offerings such as installation services and offerings to support new IBM
    hardware. Although the ServicePac&reg; business is itself a single world-wide operation, their product, ServicePacs&reg;, are
    sold by numerous IBM lines of business and Business Partners. Each selling organization has its own order entry systems
    tailored to their particular line of business (and not to ServicePacs&reg;). These systems represent a veritable who's-who
    of different technologies built at different times by different teams.
</p>
<p>
    Order entry systems that handle ServicePacs&reg; must perform validations at order entry time based on requirements
    developed by the ServicePac&reg; business. ServicePac validation can be complex. ServicePacs&reg; are offered in more than 100
    countries and the offerings are not the same everywhere. The ServicePac&reg; offerings vary according to product model,
    country where delivered, sales channel, order entry system and customer-specific information such as currently owned
    ServicePacs&reg;.
</p>
<p>
    Traditionally, ServicePac&reg; order validation has been performed within the order entry system, implementing only those
    validation requirements that are needed for the sales channels supported by that system. As the ServicePac&reg; business
    has grown, the cost of communicating the validation requirements, coordinating their development, test and deployment
    has become prohibitively expensive. Furthermore, arranging for proper order validation within the ordering systems has
    significantly increased the time-to-market for new offerings.
</p>
<p align="center">
    <img height="368" alt="Image illustrates a services-oriented approach to order validation." src="./../../../rup_soa_plugin/guidances/guidelines/resources/figure1.gif"     width="491" />
</p>
<p align="center">
    <font size="-2">Figure 1 - services oriented approach to ServicePac&reg; Order Validation. The approach is to make a single
    service available to all order entry systems that process ServicePacs&reg;, rather than placing specific validation logic
    in each ordering system.</font>
</p>
<h3>
    A Services Oriented approach to validation
</h3>
<p>
    Early on it was apparent that validation needed to be the responsibility of the ServicePac&reg; business, and not each
    individual sales system through which ServicePacs&reg; are ordered. The two choices considered were to distribute code that
    encapsulated the ordering validation requirements to all of the ordering systems or to provide a centralized order
    validation service. Avoiding the governance issues associated with the distributed code approach was a major driver for
    choosing the centralized service approach.
</p>
<p>
    The greatest single benefit of exposing Order Validation as a service to order entry systems is that order entry
    systems no longer need to locally implement, test or run their own ServicePac&reg; order validation logic. Perhaps the
    greatest concern (or fear) comes from the many order entry system owners who now have a new run-time dependency on an
    external system operated by another organization. As you will learn below, the net benefit of providing the validation
    logic as a service outweighed the concerns in this case.
</p>
<p>
    Below is a quick summary of the architectural goals for the project:
</p>
<ol>
    <li>
        <strong>Interface design:</strong> The validation interface needs to be designed to gracefully handle anticipated
        evolution of the business (e.g. new product offerings should not in general require any interface
        modifications)<br />
        <br />
    </li>
    <li>
        <strong>Messaging protocol independence:</strong> The validation service should be accessible independent of the
        calling platform, programming model, network transport layer, or hardware choices.<br />
        <br />
    </li>
    <li>
        <strong>Business agility:</strong> The validation logic was implemented to make anticipated business changes safe,
        inexpensive and quick without sacrificing performance, reliability or compromising fundamental design rules.<br />
        <br />
    </li>
    <li>
        <strong>Scalability:</strong> Scaling to higher throughputs should not involve reprogramming or significant
        functional test.
    </li>
</ol>
<h4>
    Interface Design
</h4>
<p>
    Working with the business owner and business architects of all the parties that manage product nomenclature, a
    self-consistent and well-documented taxonomy was developed for the current and anticipated products. Based on the
    taxonomy, an XML data model described in XML Schema language was developed that expresses all the necessary product
    types along with their attributes. As new products are offered the taxonomy may change - along with potential schema
    changes, however, the actual message format is expected to remain unchanged so long as the new offerings fall with the
    scope of the defined taxonomy.
</p>
<p>
    This approach provides the business with the desired flexibility to quickly and inexpensively introduce new offerings.
    Of course, it does not cover all possible cases. For instance, if a new product offering has a precondition that has
    not been anticipated in the existing message definitions then new message definitions will have to be put in place.
</p>
<p>
    A simple validation request message payload that includes a single order for a single ServicePac&reg; for a customer-owned
    computer identified by its part number and serial number is shown in listing 1. The message format supports multiple
    orders for multiple ServicePacs&reg; that could be associated with both new and existing hardware. In some cases, messages
    may have thousands of nested elements.
</p>
<h4>
    Messaging protocol independence
</h4>
<p>
    One of the great advantages of using BPEL is that messaging relationships between the services are described abstractly
    in WSDL which provides a degree of messaging protocol independence. To take maximum advantage of this feature one must
    carefully avoid building implementations that depend on specific characteristics of the messaging protocol being used
    during development. For instance, if EJB bindings are being used during development, the programming style may result
    in short choppy message exchanges (i.e. frequent exchange of small messages). If at a later time the binding is changed
    to JMS or SOAP over HTTP there will likely be a serious performance bottleneck resulting from a larger per-message
    overhead for these protocols. In this case, the impact of moving between bindings can be reduced by following a
    programming style in which message exchanges are large grained (i.e. relatively infrequent exchanges of larger message
    bodies) so the overhead of message creation and receipt can be amortized over more data.
</p><br />
<table cellspacing="2" cellpadding="2" width="75%" border="1">
    <tbody>
        <tr>
            <td class="codeSample">
                &lt;?xml version="1.0" encoding="UTF-8"?&gt;<br />
                &nbsp;&lt;spkOrderDataList&gt;<br />
                &nbsp; &lt;header&gt;<br />
                &nbsp;&nbsp; &lt;orderReference&gt;1040-5124-001&lt;/orderReference&gt;<br />
                &nbsp;&nbsp; &lt;orderDate&gt;2004-08-15&lt;/orderDate&gt;<br />
                &nbsp;&nbsp; &lt;orderingSystem&gt;WEB&lt;/orderingSystem&gt;<br />
                &nbsp;&nbsp; &lt;country&gt;US&lt;/country&gt;<br />
                &nbsp;&nbsp; &lt;distributionChannel&gt;A&lt;/distributionChannel&gt;<br />
                &nbsp;&nbsp; &lt;headerReturnCode/&gt;<br />
                &nbsp; &lt;/header&gt;<br />
                &nbsp;&lt;spkSegmentList&gt;<br />
                &nbsp;&nbsp; &lt;orderItemReference&gt;102&lt;/orderItemReference&gt;<br />
                &nbsp;&nbsp; &lt;spkPartNumber&gt;69P9921&lt;/spkPartNumber&gt;<br />
                &nbsp;&nbsp; &lt;spkType&gt;WMAINTOPT&lt;/spkType&gt;<br />
                &nbsp;&nbsp; &lt;spkQuantity&gt;1&lt;/spkQuantity&gt;<br />
                &nbsp;&nbsp; &lt;hardwareQuantity&gt;1&lt;/hardwareQuantity&gt;<br />
                &nbsp;&nbsp; &lt;spkReturnCode/&gt;<br />
                &nbsp;&nbsp; &lt;hardwareSegment&gt;<br />
                &nbsp;&nbsp;&nbsp; &lt;serialNumber&gt;77X9182&lt;/serialNumber&gt;<br />
                &nbsp;&nbsp;&nbsp; &lt;hardwareIdentifier&gt;8676M2X&lt;/hardwareIdentifier&gt;<br />
                &nbsp;&nbsp;&nbsp; &lt;hardwareReturnCode/&gt;<br />
                &nbsp;&nbsp; &lt;/hardwareSegment&gt;<br />
                &nbsp;&lt;/spkSegmentList&gt;<br />
                &nbsp;&lt;/spkOrderDataList&gt;<br />
                &lt;/ServicePacData:validationRequest&gt;
            </td>
        </tr>
    </tbody>
</table><br />
<p>
    Listing 1 - Sample of a simple message received by the validation service composed of a single order for a single
    ServicePac&reg; that will be applied to an existing computer which is identified by its part number and serial number. The
    validation service returns the received message annotated with either verification codes or error codes. The invoking
    component can provide its own reference numbers to allow it to correlate the request and response.
</p>
<p>
    Another consideration for protocol independence is messaging style. In this project future needs for asynchronous
    messaging was addressed by creating validation message definitions with a (currently unexploited) field for correlating
    request and response messages, even though all current usage is synchronous and therefore needs no correlation.
    Addressing such concerns typically spans both the message design and the application design.
</p>
<h4>
    Business Agility
</h4>
<p>
    Fundamentally, the ServicePac&reg; validation service accepts an order and returns information indicating whether the order
    is valid or not, and if not why not. The key though, is to minimize the re-design, re-test and performance impact when
    modifications need to be made in response to new business requirements. Clearly, it is useful to have an idea of what
    the new requirements are likely to be when designing the initial implementation.
</p>
<p>
    Initial implementation details:<br />
    <br />
    The validation service extracts the ServicePac&reg; order details consisting of: ServicePac&reg; types, the hardware it is
    destined to be applied to, the ServicePac&reg; delivery location (country), the sales channel and the customer data.
    Business logic then tests the order information against a collection of declarative statements provided by the
    ServicePac&reg; business. The set of tests that must be applied to any given order depends on the order details. Some of
    the tests require access to additional data that is only available from remote systems.
</p>
<p>
    There are three types of data required to validate an order: reference data owned by this application, cached reference
    data owned by other systems, and live data that must be obtained from other systems each time an order is validated.
</p>
<p>
    Reference data owned by this application is accessed through a partner service that was built as part of this
    application. This service is also available to other applications that need access to reference data owned by this
    application.
</p>
<p>
    Reference data owned by other applications is provided by accessing a partner service built as part of this
    application. Where possible the partner service caches the data obtained from other applications in order to minimize
    the number of network accesses. By locating the caching strategy within the partner service, it can be changed as
    needed over time without requiring changes to the rest of the application.
</p>
<p>
    Data and intermediate results that only need to be stored during the lifetime of a validation request are stored in
    BPEL variables. Using BPEL variables eliminates the overhead of avoidable accesses to partner services and therefore
    may improve overall performance.
</p>
<p align="center">
    <img height="368"     alt="Image illustrates a topological view of the work flow driven implementation of the business logic."     src="./../../../rup_soa_plugin/guidances/guidelines/resources/figure2.gif" width="491" />
</p>
<p align="center">
    <font size="-2">Figure 2 - topological view of the work-flow-driven implementation of the business logic that chooses
    which of the computationally intensive or data intensive tests must be performed in order to validate a given order.
    The same service interface is used by all of the order entry systems that need to validate orders.</font>
</p>
<p>
    At this point we switch to investigating the nature of those new requirements that can be anticipated from discussions
    with the business and looking at historical trends.
</p>
<p>
    As the ServicePac&reg; business expands, new business tests for ServicePac&reg; validation are created; however, existing tests
    are not expected to be changed. Validating new products requires evaluating a new grouping of existing and possibly new
    tests.
</p>
<p>
    This set of requirements is a good match for a work flow driven system in which the work flow is used to knit together
    sets of tests required by each product type. The aspects of the tests that are computationally or data intensive can
    then be developed in less flexible but more efficient technology and rendered as partner services available to the
    central workflow engine as shown in Figure 2.
</p>
<p>
    When new business offerings are added the validation system the workflow itself is modified to access the existing
    partner services (and possibly new partner services needed to support the new offering). Assuming the partner services
    have been properly segmented at the outset, this architecture exhibits a very attractive additive mode in which new
    requirements will not require much re-testing or re-coding of previously implemented function.
</p>
<h4>
    Scalability
</h4>
<p>
    Since the BPEL application is deployed atop a mature middleware stack that offers clustering as a configuration option,
    moving the ServicePac&reg; Validation project to footing that can easily scale by adding new hardware as needed was
    straight forward. Of course, the overall architecture of calling partner services from a workflow engine nicely fits
    the clustering model.
</p>
<p>
    As a design point, this service is idempotent since calls to this service have no caller detectable side effects.
    Hence, no error recovery actions need to be taken by a service consumer if a service call returns an error or fails to
    complete. Indeed, the service consumer can safely re-try a call at any time. The fact that the partner services are
    also idempotent significantly simplifies the factors associated with scaling the process using clustering since the
    error recovery is relatively simple and recovery and restart after a failure is straight forward. Furthermore, there is
    no need for "caller affinity" since each interaction is atomic and there is no caller specific caching associated with
    processing a request.
</p>
<h3>
    The Application of Workflow and BPEL
</h3>
<p>
    BPEL4WS (Business Process Execution Language for Web Services) is a language and programming model specifically
    designed for executing workflow based business logic that involves the choreography of web services. BPEL is an open
    standard for which many vendor implementations of both authoring tools and runtimes.
</p>
<p>
    The ability to describe the ServicePac&reg; business process through a schematic process diagram and then represent the
    implementation logic using the standards based BPEL4WS constructs provided just the right combination of flexibility
    and isolation to implement flexible ServicePac&reg; business logic.
</p>
<p>
    For this project we chose the IBM WebSphere Application Developer Integration Edition (WSADIE) as an authoring
    environment. Developed code artifacts were targeted to run on the IBM WebSphere&reg; Business Integration Server Foundation
    v5.1.1 runtime that provides a business process execution engine to subsequently execute the workflow. The data is
    hosted on a DB2 (v8.1) server.
</p>
<p>
    Individual tests needed for ServicePac&reg; validation were implemented as Enterprise Java Beans, specifically Stateless
    Session Beans, running in the WebSphere&reg; Application Server EJB container. The WSADIE tooling facilitated the
    integration of these EJBs as web services through the automated generation of WSDL files. As a result, the individual
    tests can be deployed either within the same container as the BPEL process, or in dedicated containers on other server
    instances.
</p>
<p align="center">
    <img height="763" alt="Image illustrates workflow as depicted by a graphical BPEL editor." src="./../../../rup_soa_plugin/guidances/guidelines/resources/figure3.gif"     width="641" />
</p>
<p align="center">
    <font size="-2">Figure 3 shows a graphical BPEL editor view of the validation workflow. The tool supports collapsing
    sub-processes and loops to simplify working on the details of individual pieces of the overall workflow.</font>
</p>
<p>
    Figure 3 shows the fully expanded BPEL process used to drive the ServicePac&reg; validation services as it appears in the
    WSADIE BPEL creation and editing tool.
</p>
<p>
    Significant performance improvements were achieved when an early implementation of the ServicePac&reg; validation workflow
    process was modified to take advantage of using BPEL variables for holding intermediate results rather than making
    additional calls to the partner service. You can see an example of this approach called out in Figure 3 where the list
    of tests to be performed on each element of an order is retained in a BPEL variable.
</p>
<h3>
    Overall Pros & Cons of the design
</h3>
<table width="75%" align="center" border="1">
    <tbody>
        <tr>
            <td>
                <div align="center">
                    <strong>Pros</strong>
                </div>
            </td>
            <td>
                <div align="center">
                    <strong>Cons</strong>
                </div>
            </td>
        </tr>
        <tr>
            <td valign="top">
                <div align="left">
                    1. Adding new offerings faster and less expensive<br />
                    <br />
                    2. Adding new ordering systems is less expensive<br />
                    <br />
                    3. Consistent comprehensive validation<br />
                    <br />
                    4. Validation service usage can be phased in as ordering systems are updated<br />
                    <br />
                    5. New Validation logic only needs to be implemented and tested in one place.<br />
                    <br />
                    6. Validation logic owned by the ServicePac&reg; business and not distributed across multiple foreign
                    systems.
                </div>
            </td>
            <td valign="top">
                1. Additional runtime cross-organizational dependencies<br />
                <br />
                2. Performance overhead in the form of additional network latency<br />
                <br />
                3. Requires re-engineering of existing systems<br />
                <br />
                4. Created a new centralized component that can potentially act as a single point of failure for multiple
                applications.
            </td>
        </tr>
    </tbody>
</table>
<p>
    In the case of the ServicePac&reg; application the advantages outlined above were found to provide significant value and
    the cons were all containable. Since the individual callers are being allowed to continue private validation until they
    go through a scheduled update which covers many concerns, the additional programming work of packaging up the data for
    a validation call is a small increment that can be contained in the overall project scope of the calling application.
    For those online services that have response time requirements that cannot be fulfilled by the validation service,
    inline preliminary validation can be done by the caller - with a single final validation access to the validation
    service. This strategy preserves the human factors of the calling application while at the same time preserving the
    integrity of the overall ServicePac&reg; ordering process. For some legacy systems that do not have internal web services
    protocol capability, a converter was built that accepts a private protocol and converts to a web services call (a
    vendor specific document to Web Services adapter was built for one of the callers in this project). Testing and
    demonstration of service robustness has allayed the fears of performance bottlenecks introduced by the validation
    service. By using clustering technology, the validation service throughput can be increased very quickly if the need
    arises. Finally, all things being equal, the concentration of the validation logic into a single implementation means
    that the money that would have been spent on deploying and testing several independent implementations can be spent
    testing and deploying a single implementation which we think will more than make up for any issues associated with
    having an additional single point of failure for many disparate order entry systems.
</p>
<p>
    Finally, the ability of the business to take real ownership of the validation requirements and their implementation, to
    roll out new offerings quickly, and to insure proper and consistent order validation at the beginning of the ordering
    process has empowered the business to consider addressing new opportunities that were formerly technically unachievable
    or prohibitively expensive.
</p></td>
</tr>
</table>
</div>
<table class="copyright" border="0" cellspacing="0" cellpadding="0">
<tr>
<td class="copyright">Copyright &copy; 2008 版权所有 东软集团股份有限公司&nbsp; 联系邮箱:<a href="mailto:tcoe@neusoft.com">tcoe@neusoft.com</a></td>
</tr>
</table>
</td>
</tr>
</table>
</body>
<script type="text/javascript" language="JavaScript">
				contentPage.onload();
			</script>
</html>
